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STACK-BASED ACCESS CONTROL 

This application is a continuation-in-part of U.S. patent application entitled 
"Controlling Access to a Resource, 11 filed on December 11, 1997, and accorded Serial 
5 No. 08/988,43 1 , winch is hereby incorporated by reference. 

The following identified U.S. patent applications are relied upon and are 
incorporated by reference in this application. 

U.S. patent application entitled "Protection Domains to Provide Security in a 
Computer System," filed on December 11, 1997, and accorded Serial No. 
10 - 

U.S. patent application entitled- "Secure Class Resolution, Loading and 
Definition," filed on December 11*1 997, and accorded Serial No, . 

U.S. patent application entitled "Typed, Parameterized, and Extensible Access 
Control Permissions," filed on -December 1 1, 1997, and accorded Serial No. 
15 m . 

U.S. patent application entitled "Uyer-indepsndent Security for 
Communication Channels," filed on June 26, 1997, and accorded Serial No. 
08/883,636. 

Provisional U.S. Patent Application No. 60/076,048, entitled "Distributed 
20 Computing System," filed on February 26, 1998. 

U.S. Patent Application No. 09/044,923, entitled "Method and System for 
Leasing Storage," fried on March 20, 1998. 

U.S. Patent Application No. 09/044,838, entitled "Method, Apparatus, and 
Product for Leasing of Delegation Certificates in a Distributed System," filed on 
25 March 20, 3998. 

U.S. Patent Application No. 09/044,834, entitled "Method, Apparatus arid 
Product for Leasing of Group Membership in a Distributed System," filed on March 
20, 1998. 

U.S. Patent Application No. 09/044,916, entitled "Leasing for Failure 
30 Detection," filed on March 20, 1998. 

U.S. Patent Application No. 09/044,933, entitled "Method for Transporting 
Behavior in Event Based System," filed -.on March 20, 1998. 



WO 



PCT/lfSM«3389 



-2r 

U.S. Patent Application No. 09/044,9 ! 9, entitled "Deferred Reconstruction of 
Objects and Remote Loading for Event NWlcadosin a Distributed System," filed on 
March 20, 1998. 

IIS, Patent Application No. 09/044,938, entitled "Methods and Apparatus for 
Remote Method Invocation; 1 filed on March 20, 1998. 

U.S. Patent Application No. 09/045,652, entitled "Method and System for 
Deterministic Hashes to Identify Remote Methods," filed on March 20, 1998. 

U.S. Patent Application No. 09/044,790, entitled "Method and Apparatus for 
Determining Status of Remote Objects in a Distributed System," filed on March 20, 
1998. 

U.S. Patent Application No. 09/044,930, entitled "Downloadable Smart. 
Proxies for Performing Processing Associated with a Remote Procedure Call in a 
Distributed System," filed on March 20, 1998, 

U.S. Patent Application No. 09/044,917, entitled "Suspension and 
Continuation of Remote Methods," filed on March 20, 1998. 

U.S. Patent Application No. 09/044,835, entitled "Method and System for 
Multi-Entry and Multi-Template Matching m a Database, 5 ' filed on March 20, 1998. 

U.S. Patent Application No. 09/Q44,$39, entitled "Method and System fid? In- 
Placc Modifications in a Database," filed on March 20, 1998. 

U.S. Patent Application No. 09/044,945, entitled "Method and System for 
Typesafe Attribute Matching in a Database," filed on March 20, 1 998. 

U.S. Patent Application No. 09/044,931, entitled "Dynamic Lookup Service in 
a Distributed System," filed on March 20, 1998. 

U.S. Patent Application No. 09/044,939, entitled "Apparatus and Method for 
Providing Downloadable Code for Use in Communicating with a Device in a 
I >isi .bu?ed System," filed on March 20, 1998. 

U.S. Patent Application No. 09/044,826, entitled "Method and System for 
Facilitating Access to a Lookup Service," filed on March 20, I99S. 

U.S. Patent Application No. 09/044,932, entitled "Apparatus and Method for 
Dynamically Verifying Information in a Distributed System," filed on March 20, 
1998. 
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U.S. Patent Application No. 09/030,840, entitled "Method and Apparatus for 
Dynamic Distributed Computing Over a Network.'' and filed on February 26, 1998. 

ippikatk 09,0^,^36, erdxued " An Interactive Design Too! 
for Persistent Shared Memory Spaces," Sled on March 20, 1998. 

U.S. Patent Application No. 09/044,934, entitled "Fob- morphic Foken-Bssed 
Control," filed on March 20, 1998, 

U.S. Patent Application No, 09/044,944, entided "Stack-Based Security 
Requirements," filed on March 20, 1998. 

U.S. Patent Application No. 09/044,837, entitled "Per-Method Designation of 
Security Requirements," filed on March 20, 1998, 

Hie present invention is directed to security measures in a computer system 
and, more particularly, to systems and methods that control access to a resource based 
on the source of the code and fee identity of the principal on whose behalf fee code is 
being executed. 

As the use of eomputer systems grows, organizations are becoming 
increasingly reliant upon them. A malfunction in the c< ■** puter s: em can severely 
hamper the operation of such organizations. Thus, organizations that use computer 
systems are vulnerable to users who may intentionally or unintentionally cause the 
computer system to malfunction. 

One way to compromise the security of a eomputer sy stem is to cause the 
computer system to execute software that performs harmful actions on the computer 
system. There are various types of security measures that may be used to prevent a 
computer system from executing harmful software. One example is to check all 
software* c i s s em with a "virus" checker. However, virus 

checkers only search for very specific software instructions. Therefore, many 
software-tampering mechanisms go undetected by a virus checker. 

Another very common measure used to prevent the execution of software thai 
tampers with a computer's resources is the "trusted developers approach." According 
to fee trusted developers approach, system administra limit the software feat a 
computer system can access to only software developed by trusted software 
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developers. Such trustee des\ , isj include, for example, well known vendors 
or ia-house developers, 

Fundamental to the trusted developers approach is the idea that computer 
programs are created by developers, and that some developers can be trusted to 
produce software that does not compromise security. Also fundamental to the trusted 
developers approach is the notion that a computer system executes only programs that 
are stored at locations that are under control of the system administrators. 

Recently developed methods of running applications involve the automatic 
and immediate execution of software code loaded from remote sources over a 
network. When the network includes remote sources that are outside the control of 
system administrators, the trusted developers approach does not work. 

One conventional attempt to adapt the trusted developers approach to systems 
that can execute code torn remote sources is referred to as the trusted source 
approach. An important concept of the trusted source approach is the notion mat the 
location from which a program is received (i.e., the "source" of the program) 
identifies the developer of the program. Consequently, the source of the program may 
be used to det ermine whether the program is from a trusted developer. If the source is 
associated with a trusted developer, then the source is considered to be a "trusted 
source" and execution of the code is allowed. 

One implementation of the trusted source approach is referred to as me sand 
box method. The sand box method allows all code to he executed, but places 
restrictions on remote code. Specifically, the sand box method permits all trusted 
code fell access to a computer system's resources and ah remote code limited access 
to the resources. Trusted code is usually stored locally on the computer system under 
the direct control of the owners or administrators of the computer system, who are 
accountable for the security of the trusted code. 

One drawback of the sand box approach - hatth approach is not very 
flexible because it restricts access by remote code to the same limited set of resources. 
Conflicts can then arise when remote code from several sources attempt to access the 
same resources. As a result, conventional systems often limit access by remote code 
from one source to one set of computer resources, while limiting access by remote 



e a possible breach insecurity. 



n the source of the 
e i* being executed. By regulating 
code access based on either or both of these factors, the security in computer systems 

invokes a plurality of methods that operate upon code during execution. The system 
includes a policy file, a call stack, and m execution unit The policy file stores 
ps^ssions for the resource. The permissions authorize -particular types of access to 
the resource based on a source of the code and an executor of the code. The call stack 
stores representations of the methods and exe tutors > ■ . s n order of invocation by the 
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it of the invention and, together with the 
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Fig. 4 is a diagram of an exemplary security mechanism illustrating the use of 
protection domains; 

Fig, 5 is a diagram of an exemplary policy implemented through use of the 
policy fde of Fig. 4; 

Fig. 6 is a diagram of a call stack associated with a thread executing on the 
computer of Fig. 2; and 

Fig. 7 is a flowchart of processing performed by the check permission, method 
erf Fig. 6 in an implementation consistent with the principles of the present invention. 

The following detailed description of the invention refers to the accompanying 
drawings. The same reference numbers in different drawings identify the same of 
similar elements. Also, the following detailed description does not limit the 

te cape f the invention is defined by the appended claims. 
Systems and methods consistent with the principles of the present invention 
increase security by pn ■ , iding flexible designation of access privileges to code. The 
systems and methods not only base the access privileges on the source of the code 
(is. , whether the code is trusted or untrusted), but also on the identity of the principal 
on whose behalf the code k being executed (i.e., whether the principal requesting the 
code execution is trusted or untrusted). 

OVERVIEW OF THE DISTRIBUTED SYSTEM 
Methods and systems consistent with fee present invention operate in a 

\ n ("the exemplary distributed system") with various components, 
including both hardware and software. The exemplary distributed system (1) allows 
users of the system to share sendees and resources over a network of many devices; 
(2) provides programmers with tools and programming patterns that allow 
development of robust, secured distributed systems as id - s the '.ask of 

administering the distributed system. To accomplish these goals, the exemplary 

n u c sys em utilizes the Java™ progranu ung \ ironment to allow both code 
and data to be moved from device to device in a seamless manner. Accordingly, the 
exemplary distributed system is layered on top of the Java programming environment 
and exploits the characteristics of this en\dronment, including the security offered by 
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it and the strong typing provided by it. The Java programming environment is more 



federated into what appears to the user to be a single system. By appearing as a single 
system, the exemplary distributed system provides the simplicity of access and the 
power of sharing that can be provided by a single system without giving up the 
flexibility and personalized response of a personal computer or workstation. The 
exemplary distributed sy stem may contain thousands of devices operated by users 
who are geographically disperse, but who agree on basic notions of trust, 
administration, and policy. 

Within the exemplary distributed system are various logical groupings of 
services provided by one or more devices, and each, such logical grouping is known as 
a Djinn. A "service" refers to a resource, data, or functionality that can be accessed by 
a user ); program, device, or another sendee and that can be computational* storage 
related, communication related, or related to providing access to another user. 
Examples of services provided as part of a Djinn include devices, such as printers, 
displays, and disks; software, such as appfications or utilities; information, such as 
databases and files; and users of the system. 

Both users and devices may join a Djinn. When joining a Djinn, the user or 
device adds zero or more services to the Djiaa and may access, subject to security 
constraints, any one of the services it contains. Thus, devices and users federate into a 
Djinn to share access to its services. The services of the Djinn appear 
progtaramats* air- sbjects of the Java programming environment, which may 
include other objects, software components written in different programming 
languages, or hardware devices. A service has an interface defining the operations 
that can be requested of that service, and the type of the service determines the 
interfaces that make up that service. 

Fig, 1 d^p :■ < mpiary distributed system 1000 containing a computer 
1 100, a computer 1 200, and a device 1300 interconnected by a network 1400. The 
computers T > <^ i c ivent a* vomputers, such as IBM- 



ciearly described in Jaworski 
incorporated herein by reference. 

In the exemplary distributed system, difft 
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iters and devices are 



WO 99/4413? 



-9- 

compatihie computers, or even "dumb" terminals. During typical operation, 
computers 1 100 and 1200 tms estst Usb I hip to transmit and 

retrieve data. 

The device ! 300 may be my of a number of devices, such as a printer, fax 
machine, storage device, computer, or other devices. The network 1400 may be a 
local area network, wide area network, or the Internet. Although only two computers 
and one device are depicted as comprising the exemplary distributed system 1000, one 
skilled in the art will appreciate that the exemplary distributed system 1000 may 
include additional computers or devices. 

Fig. 2 depicts the computer 1 100 m greater detail to show a number of the 
software components of the exemplary distributed system 1000. One skilled in the art 
will appreciate that computer 1200 or device 1300 may he similarly configured. 
Computer 1 100 includes a memory 2100, a secondary storage device 2200, a central 
processing unit (GPU) 2300, an input device 2400, and avid® I - a 2500. The 
memory 2100 includes a lookup sen-ice 21 10, a discovery server 2120, and a Java™ 
runtime system 2130. The Java runtime system 2130 includes the lava™ remote 
method invocation systesh <S^3 2140 and a Java™ virtual machine (JVM) 2150. 
The secondary storage device 2200 includes a Java™ space 2210, 

As mentioned above, the exemplary distributed system 1 000 is based on the 
Java programming environment and thus makes use of the Java .runtime system 2130. 
The Java runtime system 2130 includes the Java™ application programming interface 
(API), allowing programs running on top of the Java runtime system to access, in a 
platform-independent manner, various system functions, including windowing 
capabilities; and networking capabilities of the host operating system. Since the Java 
API provides a single common API across all operating systems to which the Java 
runtime system 2130 is ported, the programs running on top of a Java runtime system 
run in a platform-independent maimer, regardless of the operating system or hardware 
configuration of the host platform. The Java runtime system 2130 is provided as pari 
of the Java™ software devek vaJ lable from Sun Microsystems of 

Mountain View. California. 
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The JVM 2150 also facilitates platform independence. The JVM 2 1 50 acts 
like an abstract computing machine, receh ing s ixcti s from programs in the form 
of byte cades and interpreting these byte codes by dynamically converting them into a 
form for execution, such as object code, and executing them, SMI 21 
remote method invocation by allowing objects executing on one computer or device 
to invoke methods of an object on another computer or device. The RMI may be 
located within the JVM, and both the RMI and the JVM are provided as part of the 
Java software development kit 

The lookup service 2110 defines the services that are available for a particular 
Djinn. That is, there may be more than one Djinn and, consequently, more than one 
lookup sendee within the exemplary distributed system 1000. The lookup service 
2110 contains one object for each service \ i < ontains 

various methods that facilitate access to the corresponding service. The lookup 
service 21 10 and its access are described in greater detail in co-pending U.S. Patent 
Application No. 09/044,826, entitled "Method and System for Facilitating Access te a 
Lookup Service," which has previously been meorporated by reference. 

The discovery' server 2 i 20 detects when a new device is added to the 
exemplar)' distributed system 1000 during a process known as boot and join or 
discovery, and when such a new device is detected, the discover)' server passes a 
reference to the lookup service 21 10 to die new device, so that the new device may 
register its services with the lookup service and become a member of the Djinn. After 
- - v c <v device becomes a member of fee Djinn, and as a result, it may 
access all fee services contained in fee lookup service 21 10. The process of boot and 
join is described in greater detail in co-pending U.S. Patent Application No. 
Q C £ ,939, entitled "Apparatus and Method for providing Downloadable Code for 
Use in Communicating with a Device in a Distributed System," which has previously 
been incorporated by reference. 

Hie Java space 2210 is an object repository used by programs within the 
exemplary distributed system 1000 to store objects. Programs use the Java space 
22 10 1 store c jjects pe rs st« k accessible to other devices 



PCT/US99/93389 



withm the exemplary distributed system. Jaw spaces are described is greater detail in 
co-pending U.S. Patent Application > OS/971,52 n t ec ''Database System 
Employing Polymorphic Entry and Entry Matching," assigned to a common assignee, 
filed ob November 17, 1997, which is incorporated herein by reference. One si ill td 
m the art will appreciate that the exemplary distributed system 1 000 may contain 
many lookup services, discover)'' servers, and Java spaces. 

FUNCTIONAL OVERVIEW 
A security enforcement mechanism is provided in which the access 
permissions of a thread are allowed to vary over time based on the source and 
executor of the code currently being executed. The source of the code indicates 
whether the code Is from a trusted or untwisted" source.. Use executor indicates me 
principal on whose behalf the code Is being executed. For example, the executor may 
be a particular user or a particular organization on whose behalf the process or 
program is operating on a client computer. 

When a routine that arrives from a trusted source is executing, the thread 
executing the routine is typically allowed greater access to resources. Similarly, a 
trusted executor may he given greater access to resources. 

When a routine calls another routine, the thread executing the routines is 
associated with permissions common to both routines. Thus, the thread is restricted to 
a level of access that is less than or equal to the level of access allowed for either 
routine. 

The mechanism allows certain routines to be "privileged." When determining 
whether a thread is able to perform an actios, only the permissions associated with the 
privileged routine and the routines above the privileged routine in the calling 
hierarchy of the thread are inspected. 

According to an implementation consistent with the present invention, the 
security mechanism described herein uses permission objects and protection domain 
objects to store information that models the security policy of a system. The nature 
and use of these objects, as well as the techniques for dynamically determining the 
ccess privi eges ">t a th eac an. described hereafter in greater detail. 
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TRUSTED AND UNTRUSTED SOURCES 
Fig. 3 is a diagram of a code stream 3100 executing in computer 1 100 (Fig. 2). 
The code stream 3 100 is executed by a cod- sen as JVM 

2130, and may derive from zero or more untrusted sources 3300 or zero or more 
5 trusted sources 3400. Untreated sources 3300 and trusted sources 3400 may be file 
servers, including file servers connected to the Internet, or other similar devices. An 
untrusted source is typically not under the direct control of the operator of computer 
11 00. Code from untrasted sources is herein referred to as untreated code. 

Because untrusted code is considered to pose a high security risk, the set of 
1 0 computer resources that untrusted code may access is usually restricted to those which 
do aot pose security threats. Code from a trusted source is code usually developed by 
trusted developers. Trusted code is considered to be reliable and poses much less 
security risk than untrusted code. 

Software code which is loaded over the network from a remote source and 
15 immediately executed is herein referred to as remote code. Typically, a remote source 
is computer system of a separate organization or individual. The remote source is 
often connected to the Internet 

Morrnaliy untrusted code is remote code. However, code from sources local to 
computer i 1 00 may pose a high security risk. Code from such local sources may be 
20 deemed to be untrusted code from an untrusted source. Likewise, code from a 

particular remote source may be considered to be reliable and to pose relatively little 
risk, and thus may be deemed to be trusted code from a trusted resource. 

According to an implementation consistent with the present invention, a 
security mechanism is used to implement security policies that allow trusted code to 
25 access more resources than untrusted code, even when the trusted and untrusted code 
are executed by the same principal. A security policy determines what actions code 
execution element 3200 will allow the code within code stream 3 1 00 to perform. The 
use of permissions and protection domains allows policies that go beyond a simple 
trested/untrusted dichotomy by allowing relatively complex permission groupings and 
30 relationships. 
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Protection domains and policies that may be used in a • , - i wife typed 
yt ^ , r. greats snce *o Fig. 4. 

TRUSTED AND IMTRUSTED EXECUTORS 

The user or organization on whose behalf a computer pro-am is operating (or 
in some circumstances, the program itself) is known as the "executor" (i.e., the 
principal on whose behalf resources will be accessed). The executor for a program on 
fee computer 1200 (a "client executor"), for example, may be different than the 
executor for a program on the computer 1 100 (a "server executor") 

Code execution element 3200 receives the request on behalf of a client 
executor via fee EMI 2140 (Fig. 2). In response, code execution element 3200 
executes an operation, such as a thread, to handle the request. The thread is 
responsible for obtaining the appropriate code and/or resources to satisfy the request, 
and the thread mil, in general he permitted to operate on behalf of either or both of 
the server executor and the client executor. 

Code execution element 3200 permits authorized executors, or "trusted 
executors," greater access to computer resources because the trusted executors are not 
considered to pose a high security risk. Trusted executors may include system 
operators that need greater access to the computer resources to handle system updates 
and the like. Unauthorized executors, or "untrusted executors," are treated differently. 
Untrusted executors are considered to pose a high security risk and, therefore, are 
given limited access to the computer resources. 

According to an implementation consistent wife fee present invention, a 
security mechanism is used to implement security policies that allow trusted executors 
to access more resources than untrusted executors, even when the trusted and 
untiustsd executors request code horn a single source. A security policy determines 
what actions code execution element 3 200 will allow. The use of permissions and 
protection domains allows po it it go bej ond a simple trnsted/untrusted 

amy b> allowing relat nplex permission group g i : .onrbps 

Protection domains and policies feat may be used in conjunction with typed 
permissions shall now be described in greater detail wife reference to Fig. 4, 
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EXBMPLAET SEOJMTY MECHANISM 
An exemplary security mechanism illustrating the use of protection domains is 
shown in Fig. 4. The exemplary security mechanism includes a policy file 4100, a 
policy object 4200, a domain mapper object 4300, and one or more protection domain 
objects 4400. The security mechanism is implemented using the code execution 
element 3200 (Fig. 3). 

Code execution element 3200 executes the code it receives from code stream 
3100 (Fig. 3). for the purpose of explanation, it shall be assumed that the code from 
code stream 3 100 is object-oriented software. Consequently, the code is in the form 
of methods associated with objects that belong to classes. In response to instructions 
embodied by code executed by code execution element 3200, code execution element 
3200 creates one or more objects 4500. An object is a data structure containing data 
combined with the procedures or functions that manipulate the data. All objects 
belong to a class, such as class 4600, Each object belonging to a class has me same 

t - i and the same methods. The methods are the procedures, 
functions, or routines used to manipulate the object. An object is said to be an 
"instance" of the class to which the object belongs. 

One or more class definitions are contained in the code from code stream 
3100; The fields and methods of the objects belonging to a class are defined by a 
class definition. These class definitions are used by code execution element 3200 to 
create obj ects which are instances of the classes defined by the class definitions. 

These class defimiions are generated from source code written by a 
programmer. For example, a programmer using a Java development kit enters source 
code that conforms to the Java programming language into a source file. The source 
code embodies class definitions and other instructions which are used to generate byte 
codes that control the execution of the code execution element 3200. Techniques for 
defining classes and generating code executed by a code execution element, such as a 
lava virtual machine, are well known to those skilled in the art. 

Each class defined by a class definition from code stream 3 100 is associated 
with a class name 4620 and a cods lea iier 4< 40. Code execution element 3200 
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maintains an association betwesi a c!l S2G and code 

identifier 4640, The code identifier 4640 represents a source of she code, 

A"soi5rceofc«de"isanentits Srcr-^ i I on nations are received. 

Examples of sources of code include 2 ilk or persistent obj ect stored on a data server 

5 connected over a network, a Flash EPROM reader that reads instructions stored on a 
Flash EPROM, or a set of system libraries. 

In an implementation consistent with the present invention, the code identifier 
4640 is a composite record containing a uniform resource locator ("URL") 4642 and a 
set of public crypt< raj e\3 4644. A URL identifies a particular source. The 

10 URL 4642 is a string used to uniquely identify any server connected to the Internet. 
The URL 4642 may also be used to designate sources local to computer \ 1 00. 
Typically, the URL 4642 includes a designation of the file and the directory of the file 
that is die source of the code stream that a server is providing. 

A public cryptographic key, herein referred to as a "key," is used to validate 

15 the digits % at .'e which may be included in a file used to tran -sport related code and 
data. Public cryptographic keys and digital signatures are described in further detail 
in Schaeier,. Applied. Cryptogtag&fr. l996 * Jhs ke >' s 4644 ffia >' obtained is the 
Hie, contained in a database associating keys with sources (e.g. , URLs), or accessible 
using alternative techniques. 

20 A class may be associated with the digital signature included in the file used to 

transport code defining the class, or the class defini tion of the class may be 
specifically associated with a digital signature. A class that is associated with a valid 
J ; ;! signature is referred to as being signed. Valid digital signatures are digital 
signatures that can be verified by known keys stored in a database. If a class is 

25 associated with a digital signature that cannot he verified, or the class is not a< » , 

with any an 1 n re, *he class is referred to as being unsigned. Unsigned classes 
may he associated with a default key. A key may he associated with a name that may 
be used to look up the key in a database. 

While one code identi ties § insat hs i s 3 d scribed as including data 

30 indicatisg a source (/. e. , cryptographic key and URL), alternate formats are possible. 
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Other information indicating the source of the code, or combinations thereof, may be 
used to represent cods identifiers. 

An executor I : 4700 represents the executor of code. An "executor of 
code" is a principal (e.g., a user or organisation) on whose behalf the code is being 
executed. An example of an executor might include a person, like "John T. Smith," or 
aa organization, like "Sura Microsystems, Inc." An "executor identifier" is, therefore, 
some form of identifier that represents the executor. Examples of possible executor 
identifiers include string names, computer system login names, and employee 
•numbers, When a server receives a request from a client via the RML the server may 
require authentication of the client executor as proof feat die client program is 
executing on behalf of the client executor. 

PROTECTION DOMAINS AND PERMISSIONS 
According to an implementati - - < at invention, 

protection domains are used to enforce security within computer systems. A 
protection domain can be viewed as a set of permissions granted to one or more 
executors when code from one or more sources is being executed on their behalf. A 
permission is an authorization by the computer system that allows a principal to 
execute a particular action or function. Typically, permissions involve an 
authorization to perform an access to a computer resource in a particular manner, Alt 
example of an authorization is an authorization to "write" to a particular directory in a 
file system (e.g., /home). 

A permission can be represented in numerous ways in a computer system. For 
example, a data structure containing text instructions can represent permissions. Aa 
instruction such as "permission executor write /somedirectory/somefile" denotes a 
permission to write to file "somefiie" in the directory "/somedirectory" on behalf of 
the principal "executor," The instruction denotes which particular action is 
authorized, fee executor authorized to perform the action, and the computer resource 
upon which that particular action is authorized. In this example, the particular action 
authorized is to ' write" on behalf c ' the principal "executor," The computer resources 
upon which the particular action is authorized is a file "/somedirectory/somefile" in a 
file system of computer 1100. In the example, the rile an i fee directory in which the 
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Sle is contained are expressed in a conventional form recognized by those skilled in 
the art. 

Permissions can also be represented by objects, herein referred to as 
permission objects. Attributes of the object represent a particular permission, For 
example, an object can contain as action attribute of "write," and a target resource 
attribute of "/somedirectory." A permission object may have one or more permission 
validation methods which determine whether a requested permission is authorized by 
the particular permission represented by the permission object 
POLICIES 

The correlation between permissions, executors, and code sources constitutes 
the security policy of the system. The policy of the system may be represented by one 
or more files containing instructions. Each instruction establishes a mapping between 
a particular access identifier and a particular authorized permission. An access 
identifier" < > " he permission 

specified in an instruction applies to ail obL s s to classes that are 

associated with the code ident <Iv, : >< silled in the access identifier of the instruction, 
when those objects are operated on behalf of the executor specified by the executor 
identifier in the access identifier of the instruction, 

Fig. 5 illustrates an exemplary policy implemented through use of the policy 
file 4100 (Fig. 4), The format of an instruction in exemplary policy file 4 1 00 is: 

<"permission"> <executor> <URL> <key aame> <action> <target> 
The <executor> identifies the executor of the code; the combination of the <URL> 
and the key that corresponds to <key uarne> constitute a code source; and the 
<action> and <target> represent a permission. The key is associated with a key name. 
The key and the corresponding key name are stored together in a key database. The 
key name can be used to find the key in the key database. For example, consider the 
following instruction: 

permission executor I S!e://somesouree somekey write /trnpf 
The above instruction represents - i authorization of a permission for executor 
"executorl" to write to any file in "/trap/*" by an object that belongs to the class 
associated with the code source "nle://sorncsouree" -"somekey" (i,e., URL-key name). 
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IMPOED PERMISSIONS 
One permission does not have to exactly match another permission to be 
considered "encompassed" by the other permission. When a first permission 
encompasses a second permission without matching the second permission, the first 
5 permission Is said to "imply" the second permission. For example, a permission to 
write to any file in a directory, such as "c:/, H implies a permission to write to any 
specific file in the directory, such as "c:/thisfile." As another example-, a permission 
to read the file "d:/log" granted to "all current employees of Sun Microsystems, inc." 
s n ipJ : esa permission to read the file M^og 1 * granted to a v . ; ee of that 

10 same organization. 

If a permission is represented by a permission object, the validation method 
for the permission object contains code for determining whether one permission is 
implied by another. For example, a permission to write, to any file in a directory 
implies a permission to write to an> sptas\ . that director ermissionto 
1 5 read from any file in a directory implies a permission to read tram any specific file in 
that directory. However, a permission to write doss not imply a permission to read. 
POLICY IMPLEMENTING OBJECTS 
A variety of objects may be used to implement the policy represented by the 
access identifiers to permissions mapping contained in policy file 41 00. According to 
20 the implementation illustrated in Fig, 4, in order to -efficiently and conveniently 

implement the policy, policy object 4200, domain mapper object 4300, one or more 
protection domain objects 4400, and one or more access identifiers 4800 are provided. 

Policy object 4200 is an object for storing the p > .on obtained, for 

example, from policy file 4100. Specifically pohcj p - a napping 

25 of access identifiers to permissions, and is constructed based on the instructions 

within policy file 4100. Within the policy object 4200, the access Identifiers and their 
associated authorized permissions may be represented by data structures or objects. 

Protection domain objects 4400 are created on demand when new access 
d z. mers 4800 are encountered by domain mapper object 4300. When an access 
30 j *het vex a 

protection domain object 4400 is aim id - \ related with the access identifier 4800. 
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\e, iomain mapper object 4300 maintains i i i ion demsm 

objects have bees created and the access identifiers associated with the protection 
domain objects. If a protection domain object is already associated with the access 
identifier, the domain mapper object 4300 adds a mapping of the access identifier and 
5 protection domain object to a mapping of access identifiers and protection domain 
objects maintained by the domain mapper object 4300, 

If a protection domain object is not associated with the access identifier, a sew 
protection domain object is created and populated with permissions. The protection 
domain- object is populated with those permissions that are mapped to the access 
10 identifier based on the mapping of access identifiers to permissions in the policy 

object 4200. Finally, the domain mapper object 4300 adds a mapping of the access 
identifier and protection domain object to the mapping of access identifiers and 
protection domain objects as previously described, 

la other implementations consistent with the press n t -> f cad of 

1 5 storing the q apping < f access identifiers to protection domain objects in. a domain 
mapper object, the mapping is stored as static fields in tits protection domain class. 
The protection domain class is the class to which protection domain objects 4400 
belong. There is only one instance of a static field for a class no matter how many 
objects belong to the class. The data indicating which protection domain objects have 
20 been created and the access identifiers associated with the protection domain objects 
is stored In static fields of the protection domain class. 

Static methods are used to access and update the static data mentioned above, 
c i * s are invoked oa behalf of the entire class, and may be invoked without 
referencing a specific object. 
25 EXEMPLARY CALL STACK 

The permission objects, protection domain objects, and policy objects 
described above are used to determine access rights of a thread. According to an 
mpien snt ion sos astern v* rib the present invention, such access rights vary over 
time based on what code the thread is currently executing, and on which executor's 
30 behalf the thread is currently > csuited in 

execution of the currently executing code of a thread is reflected in the call stack of 
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the thread. Reference to an exemplary call stack shall be made to explain the 
operation of a seci 3 m that enforces access rights in a way that allows the 

rights to van 1 over time. 

Fig, 6 is a block diagram that includes a call stack 6 s 00 associated with a 
thread 6200 in which the method 63004 of an object 4500-1 calls the method 6300-2 
of another object 4500-2 that calls the method 6300-3 of yet another object 4500-3 
that calls a cheek permission method 6400 of an access controller object 6500, 

Thread 6200 is a thread executing on computer 1 100, Call stack 61 00 is a 
stack data structure representing a calling hierarchy of the methods invoked by thread 
6200 at any given instance. At the instance illustrated in Fig. 6, call stack 6 100 
contains a frame (e.g., frame 6100-1) for each method executed by thread 6200, but 
not yet completed. 

Each frame corresponds to the method that has been called but not completed 
by thread 6200, The relative positions of the frames on the call stack 61 00 reflect the 
invocation order of the methods that correspond to the frames. When a method 
completes, the frame that corresponds to the method is removed from the top of the 
call stack 6 1 00, When a method is invoked, a frame corresponding to the method is 
added to the top of the call stack 6100. 

Each frame contains information about the method and the object that 
correspond to the frame. From this information, the class of the method can be 
determined by invoking a "get class" method provided for every object by the code 
execution element 3200. The code identifier of this class can then be determined from 
the association maintained by the code execution element 2200. Each frame also 
contains the executor identifier (e.g. , executor identifier 4700-1) of the executor on 
whose behal s - < is executing. The executor identifier and code identifier can 
then be composed into an access identifier (e.g. , access identifier 4800-1). From the 
mapping in domain mapps . the protection domain object associated with 

the access identifie for a| iven fran 2 :an >e k en used 

For example, assume thread 6200 invokes method 6300- 1 . While executing 
method 6300-1, thread 6200 invokes method 6300-2, While executing method 6300- 
2, thread 6200 invokes method 6300-3, While - 5 -read 6200 
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mvokes method 6400. At I - hierarchy 

of methods as shown in Fig, 6. Frame 6100-4 corresponds to method 6400 frame 
6100-3 to method 6300-3, frame 6100-2 to method 6300-2, and frame 6100-1 to 
method 6300-1 . When thread 6200 completes method 6400, frame 6100-4 is removed 
from the call stack 6100. 

METHOD/PERMISSION RELATIONSHIPS 
Each frame on ths call stack 6100 Is associated wi th a set of permissions. The 
set of permissions for a given frame is determined by the protection domain object 
associated with the source from which the cods for the gives method was received 
and the principal on whose behalf the code is. being executed. The relationship 
between frames, protection domains, and permissions shall now be described, with 
continued reference to Fig. 6, 

Protection domain, object 4400-1 is mapped from the access identifier 4800-1 
formed by the executor Iden I and the cod< if t the c as* uf object 
4500-1. Method 6300-1 of object 4500- 1 invokes method 6300-2 of object 4500-2 on 
behalf of executor identifier 4700-2. Protection domain object 4400-2 is mapped 
Srom the access identifier 4800-2 formed by the executor identifier 4700-2 and the 
code identifier of the class of object 4500-2. Method 6300-2 of object 4500-2 invokes 
method 6300-3 of object 4500-3 on behalf of executor identifier 4700-3, Protection 
domain object 4400-3 is mapped from the access identifier 4800-3 formed by the 
executor identifier 4700-3 and the code identifier of the class of object 4500-3. 

While protection domain objects are used to. organize and determine the access 
rights of a particular executor and code source, some mechanism must be provided to 
determine the access rights of a thread having a call stack with multiple methods 
whose code arrived from multiple sources or whose code is requested to be executed 
on behalf of multiple principals. According to an implementation consistent with the 
>reseat am ( determination is performed by an access controller object, as 
shall be described in greater detail hereafter. 

EXEMPLARY ACCESS CONTROLLER 
Aecordioi to a"! an p e ne h die present invention, an 

access controller object is used tc dete < tion ma> be 
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performed by a Unread Specifically, before a resource management object accesses a 
resource, the resource management object (eg, , object 6300-3) invokes a check 
permission method 6400 of as access controller object 6500. 

In the Illustrated example, the resource management method 6300-3 invokes a 
cheek permission method 6400 of the access controller object 6500 to determine 
whether access to the resource is authorized. To make this determination, the check 
permission method 6400 of the access controller object 6500 performs the steps that 
shall be described with reference to Fig. 7. 

DETERMINING WHETHER AN ACTION IS AUTHORIZED 
According to an implementation consistent with the present invention, an 
action is authorised if the permission retired to perform the action is included in 
each protection domain object associated with the thread at the time when a request to 
determine the authorisation is made. A permission is said to be included in a 
protection domain object if that permission is encompassed by one or more 
permissions associated with the protection domain object. For example, if an action 
requires permission to write to a Ms in the !, e:/tmp" directory on behalf of the 
principal "Bob," men that required permission would be included in protection 
domain object 4400-1 if the protection domain object 4400-1 explicitly contains or 
implies that permission. 

Assume that thread 6200 is executing method 6300-3 when thread 6200 makes 
a request for a determination of whether an action is authorized by invoking the check 
permission method 6400. Assume further that thread 6200 has invoked method 6300- 
1, method 6300-2, and method 6300-3 and these methods have not completed when 
thread 6200 invoked method 6400. The protection domain objects associated with 
thread 6200 when the request for a determination of authorization is made ate 
represented by protection domain objects 4400-1 , 4400-2, and 4400-3, 

Given the calling hierarchy present in the current example, the required 
permission to perform an action of writing to file "di/sys/pwd" on behalf of "Bob" is 
not authorized for thread 6200 because the res ; ission is not encompassed by 

any penrdssi a inch led in protection domain object 4400-1, if the only permission 
contained the? \ ■ - : re toe:/tmp." 
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PRIVILEGED METHODS 
Sometimes fee need arises to authorize an action that a method performs 
irrespective of the protection domain 1 . tssoc ?d & &e methods that precede 
the method in the calling hierarchy of a thread. Updating a password is an example of 
when such a need arises. 

Specifically, because the security of a password file is critical, the permissions 
required to update the password file are limited to very few specialized protection 
domain objects. Typically, such protection domain objects are associated with 
methods ± ; from trusted cods and trusted executors that provide their own 
security mechanisms. For example, a method for updating a password may require 
the old password of a user before updating the new password for that user . The 
method may also require authentication of the principal on whose behalf the update is 
being requested, and permit updating of the password for only authorized principals. 

Because permissions to update pa it * srecific 

sources and to code executed on behalf of specific authorized principals, code from all 
other sources or principals will not be allowed to update the passwords. This is true 
even in a situation such as that shown in Fig. 6, where code from a remote source 
(method 6300-1) attempts to change the password by invoking trusted code (method 
6300-3) which has permission to update the password. Access is denied in this 
situation because at least one method in the calling hierarchy (method 6300-1) does 
not have the necessary permission. 

According to an implementation consistent wife fee present invention, a 
privi age mechanism is provided to allow methods that do not themselves; have the 
permission to perform actions to nevertheless cause the actions to be performed by 
calling special "privileged" methods that do h&\ ; the pen ssion This result is 

bie\ i £ pi ction domain objects that are considered to be 

"associated with a thread" to only those protection domain objects that are associated 
with a "privileged" method and those methods that are subsequent to the privileged 
method in the calling hierarchy. 

A method may cause is to * avilt ged (i.e., enable the privilege 
mechanism) by invoking a method ofaprr* e c Us >r example, 
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begiriPrivilege. A method may cause itself to become privileged (i.e. disable the 
privilege mechanism) by invoking another method of the ptu p eoi c ilkd, for 
example, endPm siege The f< . ... • I stra technique for 

invoking methods that enable or disable the privilege mechanism. Although the code 
example may resemble the Java programming language by Sun Micrc s] steins (nc 
fee example is for illustrative purposes only and is not meant to be representative of 
an actual code implementation. 

Privileged p ~ new Priviieged(); 

p.heginPrivjiege0; 

try { 

(sensitive code] 
} faiially { 

p.endPrivnege(); 

} 

The first line of the code example creates a privilege object. The second line 
invoked a MginPriviiege method of the privilege object that enables the privilege 
mechanism. T&e "try finally" statement ensures that fee block of code following the 
"finally" is executed regardless of what happens during execution of the block 
between; the ■■"try* and the "finally." Thus, the privilege disabling method of the 
privilege object f p.endPriviiegeO") »s always invoked. 

The above code can be t i foi example, to botrnd the portion of mt 
6300-3 that actually accesses the password file. The portion that accesses the 
password file would be contained in the block designated as "[sensitive code]." The 
techniq ei rate he above code example exp c - c s the responsibility for 
ihv or" 1 e~v median ^ upon the p ogrammer. 

Often, while executing a pri vileged method, a thread may invoke subsequent 
methods associated with other protection domain objects that do not include 
permissions included in the privileged protection domain object When a thread is 
executing a subsequent method, an action requested by the thread is only authorized if 
the required permission is encompassed in the protection domain objects associated 

queat method mid on 5 in t ag uerarchy between the 

subsequent r >d and p >ge e vely Pie advantage of limiting the 

privilege me - is sar net s to prevent methods of untrusted code and of 
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uatrusted executors from effectively "borrowing the oerrus^ s assoeia 
xi\ Seged methods of trusted code and trusted executors when the methods of fee 
ustrusted cods and untrasted executors are invoke? - the orivileged methods. 

In as alternate Implementation consistent with the present invention, a method 
causes itself to be privileged or not privileged by invoking static methods of the 
access controller class. The access controller class is the class to which access 
controller objects belong. As demonstrated in the following code example, using 
static methods that are associated with the access controller class avoids the need of 
having to cm • ct in order to enable the privilege mechanism. 

The following code example illustrates one technique for invoking methods 

that enable or disable the privilege mechanism. Assume for the purpose of illustration 

that, the access controller class name Is AceessControl. Although the code example 

may resemble the lava programming language by San Microsystems Inc., the 

example is for illustrative purposes only and is not meant to be representative of an 

actual code implementation. 

AceessControl .beginPrivilegeO; 
try{ 

[sensitive codel 
} finally { 

AccessControLsndPrlvilegeO; 

} 

ENABLING INVOCATIONS 
A thread may invoke the same method at different levels in a calling hierarchy. 
For example, a method X may call a method Y which may call the method X. 
Consequently, a method, such as method 6300-2, that is invoked as a privileged 
method could he invoked a second time without enabling the privilege mechanism in 
the second invocation. To properly determine the protection domain objects 
s c ated with a thread while the privilege mechanism is enabled, a mechanism is 
provided to track which i 

mechanism. The invocation in which a thread enables the privilege mechanism is 
referred to as an "enabling invocation." 
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Oae technique to track which ir^ oes e enabling 

invocations is to set a flag in the frame corresponding to each enabling invocation, 
'this may be accomplished by setting the privilege flag 6150 in the frame 
corresponding to each enabling invocation, when the privilege enabling method of 
each privilege enabling object is invoked during execution of a method. 

According to an implementation consistent with the present invention, each 
frame has a privilege flag value. When any frame is added to the call stack 6 1 00, the 
initial value of the privilege flag indicates that the corresponding method is not 
privileged. Hie privilege Hag of any frame is only set to a value indicating the 
corresponding method is privileged when the corresponding method enables the 
privilege* 

After a method that enables the privilege mechanism completes, the value of 
the privilege flag 6150 will not carry over to the next invocation of the method. The 
value will not carry over because when the new frame corresponding to the method is 
added to the call stack 6100, the initial value of tie privilege flag is set to indicate that 
the corresponding method is not privileged. Maintaining the value of the privilege 
Sag in this manner disables the privilege mechanism when a privileged method 
completes regardless of whether the privilege mechanism is explici tly disabled by the 
programmer. 

Fig. 7 is a flowchart of processing perforated by the check permission method 
6400 in Fig. 6. With reference to Fig. 6, assume that the thread 6200 invokes a 
method 6300-1. During execution of method 6300-1, thread 6200 invokes method 
6300-2, then method 6300-3. Assume further that method 6300-2 is privileged. 

In step 7100. when a resource management object receives a request to access 
an object, the check permission method 6400 is invoked to determine whether the 
requested action is authorized. In Fig. 6, the method 6300-3 makes the request to 
access an object by invoking the cheek permis . d 6400 of the access 

controller object 6500. and passing to it as a parameter the permission required to 
perform the action. 

Steps 7200 through 7S00 define a loop in which permissions associated with 
the frames in the call stack are checked. The loop continues until a privileged method 
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is encountered, or all of the frames in the call stack have been checked. For the 
purpose of explanation, the frame whose privileges are cure ! x* . ; decked is 
referred to as the "selected frame," and the method associated with that frame is 
referred to est : - iect a method," 

In step 7200, s determination is made as to whether one of t 
associated with the selected inane encompasses the permission required, lite 
permissions associated with a frame are the permissions of the protection domain 
object that is associated with the frame- If the determination made in step 7200 is that 
a permission associated with the selected frame encompasses the permission required, 
control passes to step 7300. 

During the first iteration of the loop, the frame that immediately precedes the 
frame associated with the check permission method of the access controller object is 
inspected, In the example, the frame associated with the check permission method 
6400 is frame 6100-4. The frame that immediately precedes frame 6100-4 is frame 
6100-3. Consequently, during the first iteration of the loop, frame 6100-3 will be 
inspected. Frame 6100-3 is associated with protection domain object 4400-3. if a 
permission associated with protection domain object 4400-3 encompasses the 
permission required, control passes to step 7300. 

In step 7300, a determination is made of whether invocation of the selected 
method represents the enabling invocation. 'Otis determination is based on the 
privilege flag of the frame corresponding to the selected method If the determination 
is that the invocation of the selected method does not represent the enabling 
invocation, control passes to step 7400. In mis example, the privilege status of frame 
6100-3 as not set to indicate that the frame represents the enabling invocation, thus 
t i passes *o stej 7400 

In step 7400, the next frame is selected. The next frame is the frame befow the 
current frame based on the calling hierarchy represented by call stack 6100. In this 
k the frame bel< v* t ie :urrent frame 6100-3 is frame 6100-2, The method 
corresponding to frame 6100-2 is method 6300-2. 

In step 7500, a defend: u on is r a ide of whether a frame was selected in step 
7400, If a frame was selected, control reverts to step 7200. in the current example. 
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controi passes to step 7200 because frame 5100-2 was selected. In step 7200, the 

lioi that the pro do -bject associated with frame 

6100-2 (protection domain object 4400-2) includes a permission encompassing fee 
permission requked because in fee example permi > * v ' fe protection 

5 domain object 4400-2 explicit!) eacc mpasses the permission required. Control then 
passes to step 7300, 

In step 7300, the detern a s tsMe is feat the invocation a selected 

method represents fee enabling invocation because the privilege flag 6! 50 indicates 
that the invocation corresponding to frame 6100-2 is an enabling invocation. A 
10 message is transmitted indicating that the permission request is valid. Then, the 
permission cheek ends. 

By exiting the permission check at step 7300 when the selected method 
represents the enabling invocation, authorization of the requested action is based on 
the privileged protection domain object and any protection domain objects associated 
15 with methods invoked after the enabling invocation. 

Now assume that the privilege mechanism was never invoked in the current 
example. Thus in step 7300, the determination that is made is that invocation of the 
selected method does not represent the enabling invocation because the privilege flag 
6150 indicates that the invocation corresponding to frame 6100-2 is not an enabling 
20 invocation. 

In step 7400, the next frame selected is frame 6 S 00-1 because the frame below 
the current frame 6100-2 is frame 6100-1 , and the method corresponding to frame 
6100-1 is method 6300-1 . In step 7500, the determination that is made is that a next 
frame was selected in step 7400. Thus, control reverts to step 7200 again. 
25 In step 7200, fee determination that is made is that the protection domain 

object associated with frame 6100-1 (protection domain object 4400-1) does not 
include fee permission required because no permission associated with protection 
domain object 4400-1 in the example encompasses the permission required. Control 
then passes to step 7600. 
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in step 7600, a message indicating that the requested action is not authorized is 
transmitted. Irs an implement cons • a e message 

is transmitted by throwing an Exception error. 

When at least one protect on domai- ! does not 

include a permission encompassing the permission required, the requested action is 
not authorised. An action is authorized only when all the protection domain objects 
associated with a thread include fee permission required at the time that the request is 
made for a determination of whether the action is authorized. 

In an injpieire~>an > i n with the present invention, when a thread 
("parent thread") causes the spawning of another thread (" child thread"), the 
protection domain objects associated with the parent thread are "inherited" by the 
child thread. Hie protection domain objects may be inherited by, for example, 
retaining the call stack of a parent thread when the child thread is created. When the 
steps shown in Fig- 7 are executed to determine whether an action is authorized, the 
call stack that is traversed is treated as if it included fee call stack of fee parent thread. 

In another implementation consistent with the present fevention, a child thread 
does not inherit fee protection domain objects of the parent thread. In this case, the 
call stack that is traversed is treated as if it did not include fee parent's call stack. 

One advantage of basing fee authorization of a thread to perform an action on 
the protection domain objects associated with the .thread is that the permissions can be 
based on the source of fee code the thread is executing and the principal on whose 
behalf the code is being executed. 

As mentioned earlier, objects are created from class definitions in code 
received by code execution element 3200, The source of code a thread is executing is 
&e source of code of fee metho d. The source of code of a method is the source of the 
class derMtion used to define the class to which the method's object belongs. The 
executor of the code is fee principal on whose behalf the code is being executed. This 
may include the executor of a process or program operating on a client system. 

Because fee protection domain objects are associated wife fee source and 
executor of code of a method, as described previously, the permissions authorized for 
a thread can be based on the source and exeeu or of the c de< ' each me rod invoked 
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by a thread. Thus it car. be org snized so tfe . l ar source or code 

executed on behalf of a particular principal is as £ cists with the permissions 
appropriate for security purposes. 

An advantage of the privilege mechanism described above is thai performance 
of sensitive operations in which security is critical can be Hashed to methods from 
trusted sources and methods executed on behalf of trusted executors. Furthermore, 
these operations can be performed on behalf of methods based on less secure code. 
Methods performing sensitive operations typically rely on their own security 
mechanisms (e.g. , password authentication methods). When a thread invokes the 
privilege mechanism, the scope of the permissions of the privileged domain, which 
typically entail a high security risk, ate limited to the ena i jcation This 
prevents a method invoked within the privileged method, such as a method based on 
untrastsd code or an untrasted executor, from acquiring the capability to perform 
operations posing a high security risk. 

While one method of tracking which invocations are enabling invocations is 
described above, various alternative methods of tracking enabling invocations are 
possible. Therefore, it is understood .that the present invention is not limited to any 
specific method for tracking enabling invocations. 

CONCLUSION 

Systems and methods consistent \\ >le t the preset in 

provide a security enforcement mechanism in wine h % pes of a thread 

vary Over time based on the source and executor of the code being executed. 

The foregoing description of exemplary embodiments oi 2 invention 

provides illustration and description, but is not intended to be exhaustive or to limit 
the invention to the precise form disclosed. Modifications and variations are possible 
in light of the above teachings or may be acquired from practice of the invention. The 
scope of the invention is defined by die claims and their equivalents. 

Although systems and methods co sister % e present cation are 
described as operating in the exemplary distributed system and the Java programming 
environment, one skilled in the art wili appreciate that the present invention can be 
practiced In other systen md other pr< ramming environments. Additionally, 
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' 5 sgh aspects of the pteseat invention are described as being stored s memory, 
one skilled in the art will appreciate that these aspects can also be stored on or read 
from other types of computer-readable media, such as secondary storage devices, like 
hard disks, floppy disks, or CD-ROM; a carrier wave from the Internet; or other forms 
5 of RAM or ROM. Sun, Sun Microsystems, the Sim logo, Java, and Java-based 

trademarks are trademarks or registered trademarks of Sun Microsystems inc. in the 
United States and other countries. 
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!, A. system that regulates access to a resource requested by an operation 
executing on a computer, the operation invoking a plurality of factions that operate 
upon code during execution, the system comprising: 

a policy file that stores permissions for each of the functions, the permissions 
authorizing types of access to the resource based on a source of the code and an 
executor of the code; 

a call stack that stores the functions and executors as frames in an order of 
invocation by the operation; and 

an execution unit that grants access to the resource when the types of access 
authorized by the permissions of all of the functions and executors on the call stack 
encompass the access requested by the operation. 

2. Tne system of claim 1 , wherein each of the frames includes 
a code identifier that identifies the source of the code for a 

correspond! ne fh i erions, and 

an exscntor identifier that Identifies the executor on whose behalf the 
code is being executed. 

3. The system of claim 2, wherein the policy So includes 

a plurality of protection domain objects, corresponding to each of the 
frames on the call stack, that set tire access permissions for each of the 
functions by mapping the code identifier and the executor idei ! '.■ . 

4. The system of claim I , wherein the execution unit includes an access 
controller that determines whether the operation is authorized to perform a requested 
type of access on the resource, the access controller including 

means for determining whether permissions associated with each of the 
frames on the call stack encompass the type of access requested, 

means for denying the requested access when any of the permissions 
fail to encompass the t\ pe >f a< '.-ess requested, and 

means for g; ui sag ccess ti te resource when all of the permissions 
encompass the type of access requested. 
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5. The system of claim 1, wherejseach of the frames include a privilege 
flag that indicates whether a coisespoaakg function is a privileged function. 

6. The system : claim 5, wherein the execution unit includes m access 
controller that determines whether the operation is authorized to perform a requested 
type of access on the resource, the access controller mcluding 

means for determining that one of the frames has a set privilege Sag, 

means for determining whether perqtissions ass rated - & each of the 
frames on the call stack subsequent to the frame having the set privilege flag 
encompass the type of access requested, 

means for denying tire requested access when any of die permissions 
fail to encompass the type of access requested, and 

means for granting access to fee resource when all of the permissions 
encompass the type of access requested. 

7. A method that regulates access to a resource requested by an operation 
executing on a computer, the operation im oking a piure c ! motions that operate 
upon code during execution, the method comprising the steps of: 

storing permissions tor each of the functions, the permissions authorising 
types of access to the resource based on a source of the code and an executor of the 
code; 

storing, as frames in. a call stack, the functions and executors in an order of 
invocation by the operation; 

determining whether fee types of access authorized by the permissions of each 
of fee functions and executors on the call stack encompass the access requested by the 
operation; arid 

granting access to the resource when the types of access authorized by the 
permissions of all of the functions and executors on the call stack encompass the 
access requested by the operation. 

8. The method of claim 7, wherein each of the frames includes a privilege 
Sag that indicates whether a eorrr-vv^ ~ , • ' v ; » u-uaun, the 

determining step including fee substeps of: 

finding that one of the Sames has a set privilege Sag, and 



with the frames sub segues - he Same 
encompass the type of access requested, 
1 6. A computer-readable medium containing instructions for 

> file that stores permissions for each ox the funetio 
:s of actions based on a source of the code and an 
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frames on the call stack encompass the requested t> pe of ad \ ard that 
grants the requested type of action when the types of actions authorized by tS 
permissions of all of the functions and executors on the call stack encompass 
the requested type of action; and 
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FIG, 4 
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